讀書心得與實際體驗的結合與驗證
近日重新翻閱了先前讀過的專案風險管理的經典書籍─"與熊共舞(Waltzing with Bears)"。在這幾年的專案經驗累積與通過PMP的認證後，閱讀起來真是句句經典、字字衝擊內心。
本書的作者是Tom DeMarco與Timothy Lister，譯者是錢一一；作者與譯者均是軟體開發專案的一時之選，雖然有些字語、流程，與PMBOK的定義與程序不盡相同，但是可以互相整合、相互輝映！
本書的架構區分為五大段落：
(1)為什麼要去管理風險－有風險，才有利潤。為要賺取合理的利潤，就必須就承擔合理的風險。
(2)一般遭預抗拒管理風險的原因－風險主要探討失敗的可能原因，一般人已習慣「報喜不報憂」，不喜歡去觸楣頭。
(3)如何去管理風險－反果求因；將可能遭遇的原因儘可能去搜集資料；進行界定(量化)、判別重要性；提出對應的策略；時時監控已知的風險，不斷的探索未知風險；設法提出縮小與解決專案可能遭遇風險的開發方式與作法。
(4)應該承擔多少風險－既然承擔了風險就要獲取應有實際的利潤，不只風險要衡量，利潤也要衡量。
(5)風險管理的實用－檢測現有風險管理的程度，瞭解現行您的狀況。
就筆者觀感，整本書就是告訴讀者：任何事情都有可能遭預一些可預期或不可預期的問題，這是不可逃避的。因此我們要作的是去面對他、去討論他、去衡量他、去記錄他、去監視他、去減輕他、去反省他。書中提出了五個核心的問題─schedule flaw, requirement inflation, employee turnover, specification breakdown, poor productivity，也提出了建議的開發方式─主動漸進式開發方法，以及相關的工具－Earn value running。
一個軟體專案所可能遭遇的問題可概分為技術上(產品)與人為上(專案)，就筆者的經驗，會讓一個專案陷入萬劫不復的地步的問題，大都是專案管理的不當所造成。
就筆者先前參與一個號稱擁有無上經驗的”P”資深專案管理者(以下以”P”表示)所領導的金融系統開發失敗專案為例：
”P”完全陷入本書所規勸、所希望專案管理應要注意的問題，結果五個核心風險一一中的，該專案只有失敗一途。
(1)schedule flaw：”P”以樂觀無比的心情、自任發展的態度，認為深受上天的眷顧，所有風險都不會發生，因此一開始就錯估了時程的壓力，僅把合約的到期日，利用紙上作業，把往前自行推演出各階段的milestone(backward scheduling)。整個專案沒有要徑圖(Critical Path)，僅憑以往經驗，自認所推斷出的時程是無懈可擊。
(2)requirement inflation：”P”由於過份利用利害關係人間的利益衝突，反而導致每個利害關係人堅不讓步，不斷的擴大需求。
(3)employee turnover：”P”自以為擁有完全的know-how，用Frocing面對專案團隊內的決策，對於專案成員所提出但伊以往未曾碰觸的issues，則全部withdrawal，導致人員的異動頻頻。而且招募新血又希望沒有”ramp-up time”，因此人員補充困難。
(4)specification breakdown：”P”最厲害的一招就是閃躲，從需求討論、差異分析，碰到重要的關鍵點就是避而不談，或者推託以後；到了實作階段，自己同意原廠所設定的範圍，到了客戶測試，就全部一次爆發。
(5)poor productivity：專案成員喪失目標，專案沒有進展，心情不斷怠惰，因此績效不斷低落。
本書所闡述的重點，對於經濟本科，從事證券業四年後，轉入從事軟體專案開發的筆者來說，有著深切的體會，書末的參考資料與資訊也深具參考價值，因此與各位分享本書的個人心得，如有任何的意見，還請 不吝賜教。